Environment of the mvoBuild.sh #14

Open
opened 2 months ago by ano · 8 comments
ano commented 2 months ago

Is it possible to initialise some environment variables? At least,
MVO_REPO
MVO_BRANCH

It would be nice to set GET parameters for webhook and have them in the environment variables such as
MVO_ARG_arg1
...
MVO_ARG_argN

Is it possible to initialise some environment variables? At least, MVO_REPO MVO_BRANCH It would be nice to set GET parameters for webhook and have them in the environment variables such as MVO_ARG_arg1 ... MVO_ARG_argN
Owner

Let's cut your request in half:

  1. MVO_REPO, MVO_BRANCH, stuff that is stored in mvoci and is about the repo
  2. GET parameters

I actually already thought about (1) and a enviroment variable is set with the version, if I recall correctly when building a release. This could be more fleshed out, yes. I'm open for your pull request.

On (2) I'm not so sure. Technically possible - yes. I don't really see the use case however. Would you want to have different variables for different (gitea) hooks, a kind of build for push, one for releases or tags, one for ... ? I should be thinking about whether that's a good idea or whether we're breaking things with adding - in a sense - external build parameters.

Let's cut your request in half: 1. MVO_REPO, MVO_BRANCH, stuff that is stored in mvoci and is about the repo 2. GET parameters I actually already thought about (1) and a enviroment variable is set with the version, if I recall correctly when building a release. This could be more fleshed out, yes. I'm open for your pull request. On (2) I'm not so sure. Technically possible - yes. I don't really see the use case however. Would you want to have different variables for different (gitea) hooks, a kind of build for push, one for releases or tags, one for ... ? I should be thinking about whether that's a good idea or whether we're breaking things with adding - in a sense - external build parameters.
Poster
  1. To be clear: I meant not a mvoCI version. I need an information about repository and branch for which wbhook is called.

For example, I use webhook to deploy repo "mygreatapp" from branch "dev" or from "master". So I need this information inside the mvoBuild.sh to make decision where I need to put mygreatapp binary - to the test server or to the production server. In other words:

if [ "$MVO_BRANCH" = "dev" ]; then
  scp "$MVO_REPO" testserver:/opt/go/bin/"$MVO_REPO"-test
elif [ "$MVO_BRANCH" = "master" ]; then
  scp "$MVO_REPO" prodserver:/usr/bin/"$MVO_REPO"
fi

It is possible to get info about repo name and branch from webhook POST data. I will try to make patch but I not so familiar with golang to make it well.

  1. I need some time to make a good example...
1. To be clear: I meant not a mvoCI version. I need an information about repository and branch for which wbhook is called. For example, I use webhook to deploy repo "mygreatapp" from branch "dev" or from "master". So I need this information inside the mvoBuild.sh to make decision where I need to put mygreatapp binary - to the test server or to the production server. In other words: ``` if [ "$MVO_BRANCH" = "dev" ]; then scp "$MVO_REPO" testserver:/opt/go/bin/"$MVO_REPO"-test elif [ "$MVO_BRANCH" = "master" ]; then scp "$MVO_REPO" prodserver:/usr/bin/"$MVO_REPO" fi ``` It is possible to get info about repo name and branch from webhook POST data. I will try to make patch but I not so familiar with golang to make it well. 2. I need some time to make a good example...
Owner

For (1) you'll want to look at build/worker.go [1] . Most of the info you'll want to export is probably already visible in the build object, see core/models.go [2].

[1] https://codeberg.org/snaums/mvoCI/src/branch/master/build/worker.go#L287
[2] https://codeberg.org/snaums/mvoCI/src/branch/master/core/models.go#L121

For (1) you'll want to look at `build/worker.go` [1] . Most of the info you'll want to export is probably already visible in the `build` object, see `core/models.go` [2]. [1] https://codeberg.org/snaums/mvoCI/src/branch/master/build/worker.go#L287 [2] https://codeberg.org/snaums/mvoCI/src/branch/master/core/models.go#L121
Poster

How to make my own branch, push there and create pull request?

How to make my own branch, push there and create pull request?
Poster

Patch attached.

Patch attached.
Poster

About (2)

In gitlab there is possible to set variables for gitlab-runner. GET args for webhook is a way to do something like that. In other words it is a build parameters which I can set in gitea.

About (2) In gitlab there is possible to set variables for gitlab-runner. GET args for webhook is a way to do something like that. In other words it is a build parameters which I can set in gitea.
Owner

Hi.

The patch looks alright. Could you send a pull request? You'll need to fork mvoCI on codeberg (top right click on the fork-button), then clone it to your machine locally, make your change (like apply the patch, you've created), commit and push to your repository. Then you can use the Codeberg Web-UI to send a pull-request to snaums/mvoci with a description.

Using git after you've forked:

# assuming your fork is under ano/mvoCI
# this clones mvoCI to your local folder mvoCI (must not exist beforehand)
git clone git@git.codeberg.org:ano/mvoCI.git 
cd mvoCI
patch <yourpatch>

# commit your changes (will create a local commit, store the changes and create a hash one could later use to revert to that commit)
# message like "added build envirnment variables describing the build to the build script"
git commit -am "<commitmessage>" 

# send your commit to your repository
git push
# or git push origin main

Then your changes should be present in your personal mvoCI repository. Get back to codeberg, on your repository click "Pull Requests" and create a new pull request.

After that you should be able to send pull requests to other projects as well, making the life of the maintainers easier. Pull Requests can be applied in the Web-UI, so the maintainer can just apply your changes, or discuss them (in public), can make changes. With a patch, there is more manual work needed to apply the changes.

Thank you.

Hi. The patch looks alright. Could you send a pull request? You'll need to fork mvoCI on codeberg (top right click on the fork-button), then clone it to your machine locally, make your change (like apply the patch, you've created), commit and push to your repository. Then you can use the Codeberg Web-UI to send a pull-request to snaums/mvoci with a description. Using git after you've forked: ```bash # assuming your fork is under ano/mvoCI # this clones mvoCI to your local folder mvoCI (must not exist beforehand) git clone git@git.codeberg.org:ano/mvoCI.git cd mvoCI patch <yourpatch> # commit your changes (will create a local commit, store the changes and create a hash one could later use to revert to that commit) # message like "added build envirnment variables describing the build to the build script" git commit -am "<commitmessage>" # send your commit to your repository git push # or git push origin main ``` Then your changes should be present in your personal mvoCI repository. Get back to codeberg, on your repository click "Pull Requests" and create a new pull request. After that you should be able to send pull requests to other projects as well, making the life of the maintainers easier. Pull Requests can be applied in the Web-UI, so the maintainer can just apply your changes, or discuss them (in public), can make changes. With a patch, there is more manual work needed to apply the changes. Thank you.
Poster

Pull request sent.
Thank you!

Pull request sent. Thank you!
snaums added the
enhancement
label 4 weeks ago
snaums added this to the v1.0 milestone 4 weeks ago
Sign in to join this conversation.
Loading…
There is no content yet.