Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to recognise Dockerfiles with extensions #4566

Open
4 tasks done
kmehant opened this issue Jun 28, 2019 · 8 comments
Open
4 tasks done

Unable to recognise Dockerfiles with extensions #4566

kmehant opened this issue Jun 28, 2019 · 8 comments
Assignees

Comments

@kmehant
Copy link

kmehant commented Jun 28, 2019

Preliminary Steps

Please confirm you have...

Problem Description

We can name a dockerfile multiple ways. Usual way is to name it as it is either Dockerfile or dockerfile in this case GitHub recognizes a dockerfile. But it's a usual practice that developers name them with extensions like Dockerfile.dev or Dockerfile.prod or similar to it. In these case GitHub fails to recognize them as Dockerfiles.

URL of the affected repository:

All repos using Dockerfiles with extensions.
examples:
https://github.com/kmehant/foundation.mozilla.org/blob/master/dockerfiles/Dockerfile.node

Last modified on:

Expected language:

Dockerfile

Detected language:

nothing

@kmehant
Copy link
Author

kmehant commented Jun 28, 2019

@lildude @Alhadis can you please look in to it?

@stale
Copy link

stale bot commented Jul 28, 2019

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___."). Thank you for your contributions.

@stale stale bot added the Stale label Jul 28, 2019
@Alhadis
Copy link
Collaborator

Alhadis commented Jul 28, 2019

This is only a smaller part of a larger underlying issue — Linguist has no way of identifying files based upon a common prefix, only a suffix (file extension) or complete filename.

Dockerfiles aren't the only thing affected by this; many Makefiles have suffixes that match their relevant architecture; e.g., Makefile.amd64. I believe we can address this on a broader level if we introduce a new strategy to match prefixes instead of extensions.

@stale stale bot removed the Stale label Jul 28, 2019
@jglick
Copy link
Contributor

jglick commented Aug 23, 2019

Ditto Jenkinsfile.whatever (or Jenkinsfile-whatever).

@stale
Copy link

stale bot commented Sep 22, 2019

This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___."). Thank you for your contributions.

@stale stale bot added the Stale label Sep 22, 2019
@Alhadis Alhadis removed the Stale label Sep 22, 2019
@Alhadis Alhadis self-assigned this Sep 22, 2019
@jglick
Copy link
Contributor

jglick commented Sep 23, 2019

Still relevant. See https://twitter.com/brunoborges/status/1175107507909320704 for example.

@karloskalcium
Copy link
Contributor

karloskalcium commented Mar 24, 2020

Adding my vote for this one, as it impacts Jenkins, Docker, Makefile, and probably several others. If adding a more general regexp matching is complicated, we could probably get a lot of value out of simple prefix matching in the same way we do extension matching - e.g. for Groovy it might look like this:

extensions:
  - ".groovy"
  - ".grt"
  - ".gtpl"
  - ".gvy"
prefixes:
  - "Jenkinsfile."
filenames:
  - Jenkinsfile

@Alhadis
Copy link
Collaborator

Alhadis commented Jul 26, 2020

I've tentatively started work on this in the prefix-strategy branch. You can track my slow and sporadic bursts of progress there. Hopefully I can implement this without messing with the classifier… 😓

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants