I have a GitHub action workflow file that is running fine, but recently warnings about ‘set-env’ and ‘add-path’ deprecation have been brought to my attention. The fix suggested by GitHub is to use “Environment Files”; I.e. pipe values into a file managed by a GITHUB_ENV file descriptor.
My question is : Is GitHub asking me to replace the “env” block of my workflow with a step containing commands of the form ‘echo “{name}={value}" >> $GITHUB_ENV’?
I have to also ask why this is necessary, since I think it is lame, but that is really beside the point.
From my experience using python with GitHub actions, this is an issue with actions/setup-python versions 1.1.1 and earlier. You probably have a line in your workflow that reads:
uses: actions/setup-python#v1.1.1
If you upgrade to version 2 of setup-python, there will be no warning. Just change the line above to the following:
uses: actions/setup-python#v2
In order to demonstrate, the log of my v1.1.1 workflow shows the warnings you mentioned, but the warnings are resolved by using version 2
I have to also ask why this is necessary
This was announced in early Oct. 2020 this month, and pointed to a moderate security vulnerability
The #actions/core npm module addPath and exportVariable functions communicate with the Actions Runner over stdout by generating a string in a specific format.
Workflows that log untrusted data to stdout may invoke these commands, resulting in the path or environment variables being modified without the intention of the workflow or action author.
For now, users should upgrade to #actions/core v1.2.6 or later, and replace any instance of the set-env or add-path commands in their workflows with the new Environment File Syntax.
Workflows and actions using the old commands or older versions of the toolkit will start to warn, then error out during workflow execution.
So:
echo "FOO=BAR" >> $GITHUB_ENV
echo "/Users/test/.nvm/versions/node/v12.18.3/bin" >> $GITHUB_PATH
That is why a GitHub Action like actions/setup-python has a recent PR 138 in order to uses Environment files to communicate with the Runner.
But if you are using any other workflow based on actions/core, you need to upgrade said actions/core version as soon as possible.
Related
Just completed a GitHub workflow using more of them are actions, but also with one bash script.
When writing the workflow, it seems much quicker use bash script than actions.(since some actions are just do one thing. ) Why are the some reasons that we just need GitHub actions rather than bash script or python script trigger?
Or we are just supposed to use script languages for most part, then use GitHub actions for small portion of the whole workflow?
Interesting but not easy to answer with more information about what your goal is. The right answer might depend on your use case.
I have not used GitHub actions yet. Let me try to explain it anyway, starting pretty high level. Unfortunately, there's no option to add a table of contents ;) Please let me know if this helps.
1. What are GitHub Actions for?
From this "What is GitHub Actions? Benefits and examples" PDF file
GitHub Actions is a CI/CD tool for the GitHub flow. You can use it to integrate and deploy code changes to a third-party cloud application platform as well as test, track, and manage code changes. GitHub Actions also supports third-party CI/CD tools, the container platform Docker, and other automation platforms.
From docs.github.com
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository or deploy merged pull requests to production. [...]
GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository.
2. Continuous Integration/Continuous Deployment (CI/CD)
Usually, people run CI/CD tools to build, deploy, test, and run other tasks while doing that. We use another 3rd party CI/CD pipeline using Rake to build, test, and check links. Our pipeline invokes these small scripts you mention.
3. GitHub actions and scripts
From Essential features of GitHub Actions
If your job generates files that you want to share with another job in the same workflow, or if you want to save the files for later reference, you can store them in GitHub as artifacts. Artifacts are the files created when you build and test your code. For example, artifacts might include binary or package files, test results, screenshots, or log files. Artifacts are associated with the workflow run where they were created and can be used by another job. All actions and workflows called within a run have write access to that run's artifacts.
Here's the key point, I guess. You can really do a lot of crazy stuff within a workflow. All is related/specific to GitHub. Workflows are event-driven, meaning that you can run a series of commands after a specified event has occurred. For example, every time someone creates a pull request, you can automatically run a command that executes a test or other script.
4. GitHub action workflow and scripts
You can include different scripts in your workflow, e.g. using
Javascript: https://github.com/actions/github-script
Python: https://github.com/marketplace/actions/run-python-script
5. (Complex) Examples
You can check out the repository for docs.github.com for some more complex examples, see action-scripts and workflow folders. GitHub themselves seems to use it pretty heavily.
6. Advantages/Disadvantages of GitHub actions
OR: Differences to other CI tools
It took some time to find something not marketing-ish. Key points are:
beginner-friendly using YAML config files
no need to set up your own CI pipeline
You can check out this SO post from 2019 for a list of what's good and bad about GitHub actions.
In short - for readability and the DRY ("Don't repeat yourself") principle.
It's more or less the same as using functions in programming.
I can agree that some trivial actions are useless.
But "actions/checkout" for example is priceless!
Is it possible to release on GitHub through the command line with an attached file that is not pushed to a repository?
I have a file over 1GB that I easily attached through a web GitHub release page, but I want to automate that using bash.
You can from command-line, using gh: cli/cli/
create a relase
gh release create <tag> [<files>...] [flags]
upload a file to that release
gh release upload <tag> <files>... [flags]
And since Github CLI 2.4.0 (Dec. 2021), you have:
the non-interactive flag --generate-notes, which allows you to skip the editor phase.
an interactive mode to choose a tag name
There's a REST API that can be used for this purpose. It's used to upload a release asset if you know the ID for the release (which you can get by querying the release itself). You can also get the upload URL by querying the release using a GET request; that returns the upload_url attribute.
If you want an example of how to do this from the command line with curl, Git LFS has a script that it uses to do releases and upload assets which you could look at. It's a little complex, but it is reasonably comprehensive.
In addition to the gh tool and directly using the REST API (as mentioned in other answers), there are several command-line tools which let you create and manipulate GitHub releases. These are likely to be much simpler to use than directly using the REST API.
There is only one* I could identify that I could unreservedly recommend, however: github-release, which is written in Go. Binaries can be downloaded from the project's Releases page, it "dogfoods (transparently uses its own tool), and is actively maintained (as at January 2022).
Some others are:
Another Go app called github-release, released by BuildKite. However, this seems to be less actively maintained, and it doesn't transparently "dogfood" (viewing its CI results require an account with BuildKite).
For Haskell developers, there's yet another tool called github-release, created by Taylor Fausak. It seems to be actively maintained; however, no downloadable executables are provided, so you must build it yourself using a Haskell compiler and build tools.
For node.js developers, there's release-it; but as a node project, it doesn't provide executable binaries that could be invoked from Bash at all.
*If there are others that I've missed, feel free to add them in comments.
Is there a way to set the version of a github action runner?
I'd like to set the version to v2.273.6 i.e. https://github.com/actions/runner/tree/v2.273.6 as they've deprecated the usage of set-env, which I'll refactor, but to get around this and allow my code to deploy in the mean time, I'd like to rollback the version.
Unfortunately, you cannot downgrade GitHub-hosted runner yourself. GitHub-hosted runners are maintained and updated automatically by GitHub. You can, however, set up your own self-hosted runner with a particular version and use it instead. Personally, I think refactoring to environment files instead of staying with the deprecated set-env workflow command is much less effort than setting up a self-hosted runner.
This is for a repository containing a library. The library version number is incremented (manually) each time a Merge Request to master is accepted.
However, if I want to access a file from version X.Y.Z, I have to look for the commit that incremented the version number to X.Y.Z, get its date, and then look in the history of the file for the version at that date.
I would like to create a tag per version, automatically when the Merge Request to master is created. Is this possible?
I hoped it would be possible with the new GitLab slash commands, but there currently is not support for tags.
Is there any other possibility than using web hooks?
While facing the same challenge, I stumbled upon this suggestion on GitLab's former issue tracker on GitHub1:
“You can write up a script to use GitLab API to accept a merge request, get the commit of the merge and then tag that commit.” --MadhavGitlab
(just to mention that — for me that's not sufficient)
1 EDIT:
Looks like all issues have been purged from the GitHub mirror, so this link does no longer work, but luckily the relevant quote persists right here.
I first tried to do it the gitlab way, by creating a .gitlab-ci.yml file in the project top-level directory. That file can contain the commands creating the version tag. The user executing the script has to have enough permission to push to the git project, and be configured with authoring information.
I finally did it on a Jenkins server, where I created a job that is invoked when commits are pushed into a specific branch. The tag can be created in the execute shell commands.
The project that I am working on is a jQuery plugin. I have managed to get Travis CI to build a test project using Gulp/NodeJS successfully. Now I am trying to work out what workflow to use to bump the version number.
In TeamCity and MyGet there is a setting in the CI server to form a version number pattern that auto increments on each build, which can be used by the build script to update versions in the deployment files and to label the Git repo. However, in the free version of Travis CI, there doesn't seem to be an option for versioning at all.
I have read several articles on continuous deployment with Travis CI, here, here, and here, but none of them even broach the topic of versioning. Obviously, the version needs to be changed for the release. So what am I missing here?
Another problem I noted when going through the documentation is that it mentioned that Travis CI is not able to update the GitHub repository. Doesn't that basically mean it won't be able to create a Git tag?
If there is no way to version from Travis CI, then what is the typical workflow for the release process for such a plugin? Is the versioning always done manually? If so, how could there be "continuous deployment"?
Before it starts running the instructions in your .travis.yml file, Travis will set a bunch of environment variables (in the VM that is building your project) with various bits of information about your build, such as what branch is being built and so on.
You probably want one of these:
TRAVIS_BUILD_NUMBER: The number of the current build (for example, “4”).
TRAVIS_JOB_NUMBER: The number of the current job (for example, “4.1”).
But it's going to be very difficult to do anything sensible if you don't have control of the repository, because you'll need to upload a .travis.yml file into the root of your source code folder, otherwise Travis won't know what to do.
Use bumped for release versioning. When you're satisfied with the changes in master, run:
bumped release <major|minor|patch>
After you push the changes, either directly or through a release PR, you can check for the presence of new tags in Travis CI and publish the package to the registry automatically.
If you consider that every PR must end up to your enduser without thinking of the impact of such changes, then your version numbers have no meaning.
You don't give your user a way to know if it is a major change that break compatibility or a bug fix. You don't allow him to get update without worrying about backward compatibility.
Currently, the commit id is your version number.
If you want to give meaning to your version numbers then you have to think of the impact of your pull requests on the enduser (http://semver.org/). You have to choose a version number for a specific PR or a group of PR.
So basically, since you have to 'think' of a certain version number for a specific version that you want to deliver, you can't automate this process.
Release/tag creation is the way to go : )
You can accomplish this by setting up a script that would create a ~/.netrc file to access the repository. In this file you can specify something like:
machine https://github.com/xxx/yyy.git
login <blah>
And instead of putting in your credentials, you can pass an github access token. You can use the travis encrypt to register it in the .travis.yml file, and export the variable for your script's use. From there in your script, you can issue regular git commands such as:
git add <some file>
git commit -m "This is $TRAVIS_BUILD_NUMBER"
git push origin <branch>