GitHub Actions: Downloading release files from a different repository - github

I have Repo A (private, in an organization), which has a GitHub Actions workflow that builds and bundles my application into a tar.gz file and includes it as an artifact in a Release.
I have Repo B (also private, same organization) which, in the GitHub Actions workflow, needs to download the release artifacts from a specific release of Repo A, and do other things with it.
What is the modern best-practices approach to enabling this cross-repo release access within an organization? Last time I did this, we had to use a Personal Access Token for a machine user that we created, which is all sorts of bad (machine user GitHub account, long-lived secret, etc.). GitHub has since added a lot of capability with the built-in GITHUB_TOKEN secret, with OIDC support within Actions, etc. Is there a better way to achieve what I'm trying to do?

If you are using a Linux Docker container, you can try and use dsaltares/fetch-gh-release-asset which is meant to:
downloads an asset from a GitHub release and provides some release details as output.
Private repos are supported.
You can find an example here.
But it does use a GitHub token which defaults to ${{ secrets.GITHUB_TOKEN }}: make sure it is a GitHub App installation access token.

Related

Using github packages without personal access token?

The project I'm working on currently deploys our private node packages via github packages. Our current workflow is for each developer to create and maintain their own personal access token, and then we use a central account's PAT for automation in AWS.
I was wondering if it's possible to authenticate with github packages without the use of Actions or PAT's?
As of 2022-07-30
No, it is not possible to use github packages without a personal access token (PAT):
It is not possible to upload without a PAT (which makes sense as it prevents random people to upload binaries to your package repo);
It is not possible to download without a PAT (not even publicly available packages can be used);
As early as 2019-10-20, people have requested github to remove PATs as a requirement for mainly downloading public packages.
The idea is that users of libraries should not need to have a github account to access a developer's package.
Sadly, the request for pat-less package downloads was not granted by Github to this day.
If you want a package registry without a hassle, it might be wise to look for other registries, such as MavenCentral or JitPack (not necessarily meant for node packages),
or host a service yourself.
I even had to link a cached webpage, as the original question has been removed from Github community along with a bunch of related questions.
Another question on github, stating pat-less access to packages is still on the roadmap for "fall 2021" is here.
I could not find what the current status of this feature is.
Edit: It is possible to download binaries without a PAT for public repositories using jitpack.io. Jitpack builds the given jar/aar on their servers.
You can add jitpack as a repository to your build system, and use the jitpack-specified URL to reference releases, branches, or specific commits.
Sadly, there is no way to refer to packages (yet).
However, this system allows your users to use your code without needing PATs nor a Github account.
I'd like to offer an alternative.
You may use a Gradle plugin of mine (magik, I was exactly in your shoes) to easier the consumption of artifacts from your Github Packages for Gradle clients.
It require you to save your read-only PAT on the repo itself, so that the users don't have to deal with any authentication (apart using the plugin above mentioned)

Repository-Webhooks vs Github Apps - which to use?

UseCase: My current use case is to react on new Issues and post automatic comments. This is mainly specific to one or two repositories.
Thus I guess webhooks on a repository as well as Github Apps can be used. Although Github has some really good documentation on both, I'm unsure which one to use for my scenario.
What advantages / disadvantages do they have when compared?
One advantage of Github Apps is that they don't need to add a WebHook to the repository according to this answer. - Not sure why that is an advantage.
Obviously a GitHub App can be installed in different repositories and also published in the marketplace. But I could also use the same URL for Webhooks in different repositories and thus mimmic that behavior with repository-webhooks to a certain extend.
What else?
The main difference is that while webhooks generate events and send them to a given URL Github. Apps have the right to access the repositories where you install them based on the permissions you give them.
If you have a webhook that fires every time an issue is updated you will receive an event at the URL you specified, but you will not have any rights to e.g. modify that issue in Github (e.g. through an API call).
If you instead have a Github App installed in your repository and the webhook URL set in the App settings, then the event will be sent to the URL as well. However, here's the difference: behind the webhook URL you will probably have a service that uses the Github App credentials (private key or temporary tokens) to make some modifications to your Github repo.
An example:
Webhook -> logging of Pull Request changes
Github App -> automate tagging of new pull requests
What else?
You can also use GitHub Actions. For your use case, there is the issues event (which is actually a webhook). It has several activity types, including opened:
on:
issues:
types: opened
This workflow only runs when an issue is created. Afterwards, you can use the REST API (e.g. via curl) to GET the newest issue and POST a comment.
As you said this is only relevent for "one or two repositories", I think it is fine to just copy & paste that workflow. If the number of repos grows, you may want to create a dedicated action.
Speaking of custom actions, there is also an existing Auto Comment action:
on: issues
jobs:
run:
runs-on: ubuntu-latest
steps:
- uses: bubkoo/auto-comment#v1
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
issuesOpened: >
Your issue comment goes here.

Azure DevOps Repos synchronization between Organization

We have two Azure DevOps Organizations,
1. Development
2. Client
I would like to know if we can synchronize Azure DevOps Repos from one organization (Development) to different organization (Client) in a secure way?
If it is possible, what would be the best way to sync from one organization to another securely?
NOTE: We are able to manually clone the Repo from one to another organization for the first time with the help of PAT and GIT Auth but the problem arises when we want to update or re-sync the code. We have to manually re-import the repo (By deleting the existing one) to make changes.
We need to do this programmatically and to another organization.
Azure DevOps Repos synchronization between Organization
Sorry but as I know there's no such out-of-box feature available in Azure Devops Service.
There're similar user voices here: Sync between projects in same org and Automatically Sync Azure Devops Repos with GitHub Repos. Usually one organization is responsible for one product, so Azure Devops doesn't recommend cross-organization actions. But if you do want this behavior in your scenario, you can use these two directions:
1.Try free Git Tools for Azure Devops extension from Martin Hinshelwood. Some steps about how to use it:
Install it in your Development organization, it contains one Publish Git Repo task.
Create a new classic build pipeline named SyncRepos, add the Publish Git Repo task in it.
(Yaml pipeline also works well, but since this is one pipeline in which only exists one task, classic pipeline is enough)
Configure the task. We only need to configure the git repo url, so it's quite easy.
Assuming the name of same repos in another organization Client is ReposToSync, and this repos is in ProjectA. So the url you should enter in pipeline(in organization Development) should be:
See this: https://anything:PAT#dev.azure.com/Client/ProjectA/_git/ReposToSync.
(You should use a PAT which has repos-related permissions. I used Full Access one to test it easily but it should be much better if you create a PAT scoped in repos permissions. It's more secure !)
Now set the trigger, enable the CI and add all the branches into filter.
Yaml pipeline is better in step4 cause it supports trigger all branches with wildcard *. See this.
Now in Development organization, when I have any change in master and qwe branches, it will automatically trigger the pipeline to run. Then the task will sync the changes in Development's repos with repos in 'Client' organization.
Any change in Development org will start a sync, if you want to same behavior in 'Client', you also need another similar pipeline in 'Client'. And, yaml pipeline with wildcard is better if you want the pipeline to monitor newly created branch.
In additions: Apart from using the task from extension, we can also use git commands in CMD task if you're familiar with those commands.
2.Feel free to post a new feature request to our User Voice forum. If you gets enough votes, the request's priority increases and the team would consider it seriously.
Hope all above helps :)
Update1:
No matter git commands or extension, if we want to make it more secure(avoid using PAT or other secrets directly in task), we can use secrets to store the important info like PAT.
1.See create secret variable in Variable Group, then link the variable group, after that we can use $(MyPat) in task and it won't be displayed in log.
2.Also you can consider using Azure Key Valut. Related doc: Link secrets from an Azure key vault.
Today I tried a way of doing it I found in a blog post and it worked perfectly (and is tremendously easy to do).
Steps:
Create a PAT (personal access token) to your Development organization (I see you already have one so skip this step)
Go to the target repo in the Development organization, click clone and copy the url
In the Client organization import the repository with the url you have copied and with your PAT (same here, I think you already did this so skip this step)
Now clone the repo to your computer from the Client organization and add a remote to the repo in your Development organization. If you don't know about remotes, this page could help: Managing remote repositories
After this, you will be able to push and fetch from the Development organization's repo.
Source: Azure DevOps Fork Repos between two Organization - Michael Ghebremedin

Use Github Package Registry without authtoken

In my node project I would like to use both NPM and Github registries. The reason is that I use some packages as request or async, but I've made my own packages which are stored on Github Packges Registry.
I've tried to add #USERNAME:registry=https://npm.pkg.github.com/ in .npmrc, but I still need an authtoken. There is the problem: as it's for a continuous integration I don't want to use a token linked to a specific user.
So what could I do ?
Edit: I'm using Circle CI for my workflows.
You can use the default GITHUB_TOKEN associated with the repository that your workflow runs in.
If you are using a GitHub Actions workflow, you can use a GITHUB_TOKEN to publish and consume packages in the GitHub Package Registry without needing to store and manage a personal access token.
ref: https://help.github.com/en/github/managing-packages-with-github-package-registry/configuring-npm-for-use-with-github-package-registry#authenticating-to-github-package-registry
If you are not using GitHub Actions and running your build in a different CI tool then I don't think you have any choice but to use a Personal Access Token tied to a user account.

Can Gitlab expose build and coverage badges to anonymous users?

We are hosting some repository on GitHub, some other on GitLab.
Sometimes, the package is published but not the source code.
We always display build status and code coverage in README.md.
Is there a way to have build and coverage badge on GitLab always accessible to anonymous?
Since release 11.4.8 of Gitlab it's not possible to expose project's Badges through a Personnal Access Token anymore. Because of the change "
Restrict Personal Access Tokens to API scope on web requests."
The commit that removed this "workaround" was published as a security fix
An ongoing issue is currently being discussed to find another solution. Let's see how it goes.
That was followed by issue 13324
It includes:
FYI, I have a workaround for this using the GitLab API.
It assumes you have created a token in GitLab for a user (Note: That "user" needn't necessarily be Human - my use case is to display a badge on a dashboard hosted on a different VM).
<img src="https://<gitlab-uri>/<namespace>/<project>/badges/<branch>/build.svg?private_token=<token>
Update Dec. 2018: This is no loger possible through a token (see Paul B.'s answer).
This is because of "Improper Enforcement of Token Scope":
The GitLab web interface was vulnerable to an authorization issue that allowed access to the web-UI as a user using their Personal Access Token (PAT) of any scope.
The issue is now mitigated in the latest release and is assigned CVE-2018-19569.
But...:
Updated: 2018-11-28: We have received reports that this change has impacted how repo files and job artifacts are downloaded for some users.
For instructions on how to do so through the API, please see our support issue.
And you also have a current workaround which repeats the API access:
It is possible to add the project avatar to the project repository with a particular filename (logo) and then this file will be used for the avatar. There is an example here:
https://gitlab.com/issue-reproduce/project-avatar-repo
You'll be able to retrieve the files through the Repository Files API:
https://docs.gitlab.com/ee/api/repository_files.html#get-file-from-repository
Example:
https://gitlab.com/api/v4/projects/issue-reproduce%2Fproject-avatar-repo/repository/files/logo.png?ref=master